@evanrs: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

@evanrs thank you!

however, i dont fully understand what's breaking here, is this the case where you're mixing usage of interpolation and the #import syntax?

if so, do you mind adding tests here to make sure this works as expected?

also, processFragments already deals with fragment de-duplication. can you see if we can re-use that or combine the logic so we dont have multiple ways of de-duplicating fragments?

Will do, thanks for the quick response.

@jnwng I've added a test that reproduces the problem.

I'm having trouble working this change into the current flow. processFragments relies on the fragmentDefinition having loc.source, but this is absent on definitions accumulated from the interpolated documents.

My attempt quickly cascaded to changes in both parseDocument and processFragments. Can you lend some direction on what you think is best here?

@evanrs I think merging your work would be highly valuable! Are you still working with graphql-tag on your project(s)?

Thanks, @AmauryLiet, I am.

Are you experiencing this issue?

@evanrs
Yes we were doing a refacto by switching from using gql`` tags in .js files to .graphql files and that made some requests fail ;)

Do you think this PR is mergeable or is it too old now?

This looks like a great feature improvement. Anything I can do to help move this PR along?

Hey guys! Any update on this? Can we help one way or another ? @evanrs @jnwng

@Vincz thanks for reviving this issue 🙂— the test is still not passing on master.

Given the interest in this @jnwng could you provide direction? Or, help us wrangle a member from @apollographql to take the lead on this?

@AmauryLiet, I think it is too old to accept this solution — other than the test case, which remains valid. If you, @Vincz, or @mkochendorfer want an edifying experience into GraphQL's ASTs I can promise creating a new PR on this issue will provide! 😛

I came to this issue from #159 because importing a fragment from a fragment doesn't work anymore.
Are these PR solve the issue? if so, could you move forward the PR?

Simple solution that seems to have worked for me:
https://github.com/mzalewski/graphql-tag/tree/patch-1

Any reason to avoid using the graphql language printer to do this?

Converted my code into a pull request (#227) - it's probably slightly inefficient since it's parsing, printing then parsing again - but it works for now and should fix the issue until someone figures out a better solution